@twick00 Please fix the stylistic issues.

@reimannf Does this seem correct to you? Sorry to bug you years after #287 but I don't have any background on this.

I also created a codesandbox example that demonstrates the issue, but it has a few caveats:

1. Ensure the endpoint and bucket values are pointed to an S3 proxy configured with SSL
2. The S3Proxy should be running with s3proxy.cors-allow-all=true or properly configured SSL options

The extension to add Access-Control-Expose-Headers to the CORS response makes sense. Nevertheless I would make the list of Headers included in Access-Control-Expose-Headers configurable and would not hardcode ETag there.
@twick00 maybe you could look here https://github.com/gaul/s3proxy/blob/master/src/main/java/org/gaul/s3proxy/S3Proxy.java#L271-L272 as an example for allowed headers and pass it accordingly to CrossOriginResourceSharing extended constructor https://github.com/gaul/s3proxy/blob/master/src/main/java/org/gaul/s3proxy/CrossOriginResourceSharing.java#L62

@reimannf, I had those changes ready to go locally so I created a PR (#674) instead of adding to this one, however, I'm not sure if it's the right solution. The fact that nobody has brought up the issue in the last 2 years shows that few people might care about customizing that Access-Control-Expose-Headers response so I decided to start with this PR since it seems like a much lighter solution. I didn't want to introduce a new configuration knob for people, IMO Access-Control-Expose-Headers should "just work".

Seems to me like the only 2 headers that most people care about are etag and location. Heres an example of the lib that works with S3Proxy; notice that it only cares about those two headers I mentioned. For my specific case, I only care about ETag, but I could easily add location to the list of exposed headers.

If you really feel like you would prefer a new configuration knob then feel free to move over to #674 instead of this and I'll close this one.

Understand your arguments, but as you described for this specific lib, one would need already 2 headers.
I am not up to date regarding AWS S3 default CORS policy, but I think the ETag is not included there as Access-Control-Expose-Headers.
I would prefer an option, to configure the Access-Control-Expose-Headers as it would also allow custom headers to be included.
The final word has @gaul as I am not a maintainer, but my preference is #674

I'll close this for now and we can migrate to #674

Thank you @reimannf for your feedback!